Field of the Invention
The present disclosure relates to configuration services. In particular, but not exclusively, the present disclosure relates to provision of a Domain Name Service (DNS) configuration service for one or more network services provided in a cloud environment.
Description of the Related Technology
Horizontally scalable network services and applications often use DNS load balancing as a way of distributing incoming requests across the cluster of servers or virtual machines (VMs) providing the service. One of the attractions of deploying such services in a cloud environment is the ability to quickly scale the service up and down by adding or removing VMs to the cluster, but this also requires DNS records to be updated so the new VMs take their share of the load.
There are no standard application programming interfaces (APIs) for updating DNS records, so in general, services do not update DNS records themselves; either the updates can be done manually or the orchestration tools used to manage the services can be programmed to update DNS entries as VMs are added or removed from the cluster.
Some orchestration toolsets have support for DNS configuration in various environments, but this usually requires scripts to be written in a programming or scripting language. Usually these scripts are environment specific as they depend on the specific DNS APIs provided by the cloud environment.
Some orchestration toolsets, provide a relationship model for allowing different network services to locate each other and form connections, with component specific hooks that are invoked as new nodes are added to each service tier. As an example, consider an application comprising a front end tier of web servers and a back-end database which may be a clustered system.
In some known systems, the web servers are modelled as one network service and the database servers are modelled as another network service, and the administrator can grow or shrink the number of servers/virtual machines in each network service by adding or removing “service provision units”.
The orchestrator defines a relationship between the two network services, and each network service implements a number of hooks associated with that relationship. For example, if the relationship was called “database”, each service would implement hooks called “database-relation-joined”, “database-relation-departed”, “database-relation-changed” and “database-relation-broken”.
When the network services are first launched and the relationship established, the orchestrator may invoke the “database-relation-joined” hook on each service provision unit of each service for each service provision unit of the other service. So, if the web server tier initially had two service provision units and the database tier one, the hook on each of the web server service provision units would get invoked once, but the hook on the database service provision unit would get invoked twice, once for each web server service provision unit.
As service provision units are added and removed from each service, the “database-relation-joined” and “database-relation-departed” hooks are invoked, so that the service provision units in each service have an up-to-date picture of all the servers in the other service.
The service provision units can also exchange configuration data over the relation, such as Internet Protocol (IP) addresses and port numbers, using a “set-relation” method to advertise the data and a “get-relation” method to read the data. If one service provision unit does a “set-relation” call, all the service provision units in the other service get told of the change via their “database-relation-changed” hook.
Known orchestrators do not have any inbuilt support for updating DNS entries.